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Message Processing and Dispatching for the 
Simple Network Management Protocol (SNMP) 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
IANA Note 
Due to a clerical error in the assignment of the snmpModules in this 
memo, this RFC provides the corrected number assignment for this 


protocol. This memo obsoletes RFC 2262. 


Abstract 


This document describes the Message Processing and Dispatching for 
SNMP messages within the SNMP architecture [RFC2271]. It defines the 
procedures for dispatching potentially multiple versions of SNMP 
messages to the proper SNMP Message Processing Models, and for 
dispatching PDUs to SNMP applications. This document also describes 
one Message Processing Model - the SNMPv3 Message Processing Model. 
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1. Introduction 


The Architecture for describing Internet Management 
[RFC2271] describes that an SNMP engine is composed 


1) a Dispatcher 

2) a Message Processing Subsystem, 

3) a Security Subsystem, and 

4) an Access Control Subsystem. 
Case, et. al. Standards Track 


Frameworks 
of: 
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Applications make use of the services of these subsystems. 


It is important to understand the SNMP architecture and its 
terminology to understand where the Message Processing Subsystem and 
Dispatcher described in this document fit into the architecture and 
interact with other subsystems within the architecture. The reader 
is expected to have read and understood the description of the SNMP 
architecture, defined in [RFC2271]. 


The Dispatcher in the SNMP engine sends and receives SNMP messages. 
It also dispatches SNMP PDUs to SNMP applications. When an SNMP 
message needs to be prepared or when data needs to be extracted from 
an SNMP message, the Dispatcher delegates these tasks to a message 
version-specific Message Processing Model within the Message 
Processing Subsystem. 


A Message Processing Model is responsibile for processing a SNMP 
version-specific message and for coordinating the interaction with 
the Security Subsystem to ensure proper security is applied to the 
SNMP message being handled. 


Interactions between the Dispatcher, the Message Processing 
Subsystem, and applications are modelled using abstract data elements 
and abstract service interface primitives defined by the SNMP 
architecture. 


Similarly, interactions between the Message Processing Subsystem and 
the Security Subsystem are modelled using abstract data elements and 
abstract service interface primitives as defined by the SNMP 
architecture. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in RFC 2119. 


2. Overview 


The following illustration depicts the Message Processing in relation 
to SNMP applications, the Security Subsystem and Transport Mappings. 
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2.1. The Dispatcher. 


The Dispatcher is a key piece of an SNMP engine. There is only one in 
an SNMP engine, and its job is to dispatch tasks to the multiple 
version-specific Message Processing Models, and to dispatch PDUs to 
various applications. 


For outgoing messages, an application provides a PDU to be sent, plus 
the data needed to prepare and send the message, and the application 
specifies which version-specific Message Processing Model will be 
used to prepare the message with the desired security processing. 
Once the message is prepared, the Dispatcher sends the message. 


For incoming messages, the Dispatcher determines the SNMP version of 
the incoming message and passes the message to the version-specific 
Message Processing Model to extract the components of the message and 
to coordinate the processing of security services for the message. 
After version-specific processing, the PDU Dispatcher determines 
which application, if any, should receive the PDU for processing and 
forwards it accordingly. 


The Dispatcher, while sending and receiving SNMP messages, collects 
statistics about SNMP messages and the behavior of the SNMP engine in 
managed objects to make them accessible to remote SNMP entities. 

This document defines these managed objects, the MIB module which 
contains them, and how these managed objects might be used to provide 
useful management. 


2.2. Message Processing Subsystem 


The SNMP Message Processing Subsystem is the part of an SNMP engine 
which interacts with the Dispatcher to handle the version-specific 
SNMP messages. It contains one or more Message Processing Models. 


This document describes one Message Processing Model, the SNMPv3 
Message Processing Model, in Section 6. The SNMPv3 Message Processing 
Model is defined in a separate section to show that multiple 
(independent) Message Processing Models can exist at the same time 
and that such Models can be described in different documents. The 
SNMPv3 Message Processing Model can be replaced or supplemented with 
other Message Processing Models in the future. Two Message Processing 
Models which are expected to be developed in the future are the 
SNMPv1 message format [RFC1157] and the SNMPv2c message format 
[RFC1901]. Others may be developed as needed. 


Case, et. al. Standards Track [Page 5] 


RFC 2272 SNMPv3 Management Protocol January 1998 


3. Elements of Message Processing and Dispatching 


See [RFC2271] for the definitions of 
contextEngineID 
contextName 
scopedPDU 
maxSizeResponseScopedPDU 
securityModel 
securityName 
securityLevel 
messageProcessingModel 


For incoming messages, a version-specific message processing module 
provides these values to the Dispatcher. For outgoing messages, an 
application provides these values to the Dispatcher. 


For some version-specific processing, the values may be extracted 
from received messages; for other versions, the values may be 
determined by algorithm, or by an implementation-defined mechanism. 
The mechanism by which the value is determined is irrelevant to the 
Dispatcher. 


The following additional or expanded definitions are for use within 
the Dispatcher. 


3.1. messageProcessingModel 


The value of messageProcessingModel identifies a Message Processing 
Model. A Message Processing Model describes the version-specific 
procedures for extracting data from messages, generating messages, 
calling upon a securityModel to apply its security services to 
messages, for converting data from a version-specific message format 
into a generic format usable by the Dispatcher, and for converting 
data from Dispatcher format into a version-specific message format. 


3.2. pduVersion 


The value of pduVersion represents a specific version of protocol 
operation and its associated PDU formats, such as SNMPvl or SNMPv2 
[RFC1905]. The values of pduVersion are specific to the version of 
the PDU contained in a message, and the PDUs processed by 
applications. The Dispatcher does not use the value of pduVersion 
directly. 


An application specifies the pduVersion when it requests the PDU 
Dispatcher to send a PDU to another SNMP engine. The Dispatcher 
passes the pduVersion to a Message Processing Model, so it knows how 
to handle the PDU properly. 
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For incoming messages, pduVersion is provided to the Dispatcher by a 
version-specific Message Processing module. The PDU Dispatcher passes 
the pduVersion to the application so it knows how to handle the PDU 
properly. For example, a command responder application needs to know 
whether to use [RFC1905] elements of procedure and syntax instead of 
those specified for SNMPvl. 


3.3. pduType 


A value of pduType represents a specific type of protocol operation. 
The values of pduType are specific to the version of the PDU 
contained in a message. 


Applications register to support particular pduTypes for particular 
contextEnginelDs. 


For incoming messages, pduType is provided to the Dispatcher by a 
version-specific Message Processing module. It is subsequently used 
to dispatch the PDU to the application which registered for the 
pduType for the contextEngineID of the associated scopedPDU. 


3.4. sendPduHandle 
This handle is generated for coordinating the processing of requests 
and responses between the SNMP engine and an application. The handle 
must be unique across all version-specific Message Processing Models, 
and is of local significance only. 


4. Dispatcher Elements of Procedure 


This section describes the procedures followed by the Dispatcher when 
generating and processing SNMP messages. 


4.1. Sending an SNMP Message to the Network 


This section describes the procedure followed by an SNMP engine 
whenever it sends an SNMP message. 


4.1.1. Sending a Request or Notification 
The following procedures are followed by the Dispatcher when an 
application wants to send an SNMP PDU to another (remote) 
application, i.e., to initiate a communication by originating a 


message, such as one containing a request or a trap. 


1) The application requests this using the abstract service 
primitive: 
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statusInformation = 


sendPdu ( 

IN transportDomain 
IN transportAddress 
IN messageProcessingModel 
IN securityModel 

IN securityName 

IN securityLevel 

IN contextEngineID 
IN contextName 

IN pduVersion 

IN PDU 

IN expectResponse 


) 
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sendPduHandle if success 
errorIndication if failure 


transport domain to be used 
destination network address 
SNMP version 


typically, 


Security Model to 
on behalf of this 
Level of Security 
data from/at this 
data from/in this 


use 
principal 
requested 
entity 
context 


the version of the PDU 
SNMP Protocol Data Unit 
TRUE or FALSE 


2) If the messageProcessingModel value does not represent a Message 


Processing Model known to the Dispatcher, 


(implementation-dependent) 


then an errorIndication 
is returned to the calling application. 
No further processing is performed. 


3) The Dispatcher generates a sendPduHandle to coordinate 


subsequent processing. 


4) The Message Dispatcher sends the request to the version-specific 
Message Processing module identified by messageProcessingModel 
using the abstract service primitive: 


statusInformation = 
prepareOutgoingMessage ( 
IN transportDomain 
transportAddress 
messageProcessingModel 
securityModel 
securityName 
securityLevel 
contextEngineID 
contextName 
pduVersion 
PDU 
expectResponse 
sendPduHandle 
destTransportDomain 
destTransportAddress 
outgoingMessage 
outgoingMessageLength 
) 
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as 
as 
as 
as 
as 
as 
as 
as 


specified 
specified 
specified 
specified 
specified 
specified 
specified 
specified 


success or error 


by 


indication 


application 
application 
application 
application 
application 
application 
application 
application 


the version of the PDU 

as specified by application 
as specified by application 
as determined in step 3. 
destination transport domain 
destination transport address 
the message 
the message 


Standards Track 


to send 
length 
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5) 


If the statusInformation indicates an error, the errorIndication 
is returned to the calling application. No further processing is 
performed. 


If the statusInformation indicates success, the sendPduHandle is 
returned to the application, and the outgoingMessage is sent via 
the transport specified by the transportDomain to the address 
specified by the transportAddress. 


Outgoing Message Processing is complete. 


Ae dy 2xs 


Sending a Response to the Network 


The following procedure is followed when an application wants to 
return a response back to the originator of an SNMP Request. 


1) 


2) 


Case, 


An application can request this using the abstract service 
primitive: 


returnResponsePDU ( 


IN messageProcessingModel —- typically, SNMP version 

IN securityModel -- Security Model in use 

IN securityName -- on behalf of this principal 

IN securityLevel -- same as on incoming request 

IN contextEnginelD -- data from/at this SNMP entity 

IN contextName -- data from/in this context 

IN pduVersion -- the version of the PDU 

IN PDU —- SNMP Protocol Data Unit 

IN maxSizeResponseScopedPDU -- maximum size of Response PDU 

IN stateReference -- reference to state information 
-- as presented with the request 

IN statusInformation —- success or errorIndication 


<~ 


—— (error counter OID and value 
-- when errorIndication) 


The Message Dispatcher sends the request to the appropriate 
Message Processing Model indicated by the received value of 
messageProcessingModel using the abstract service primitive: 


result = —- SUCCESS or errorIndication 
prepareResponseMessage ( 

IN messageProcessingModel -- specified by application 

IN securityModel -- specified by application 

IN securityName -- specified by application 

IN securityLevel -- specified by application 

IN contextEnginelD -- specified by application 

IN contextName -- specified by application 

IN pduVersion -- specified by application 
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3) 


IN PDU -- specified by application 

IN maxSizeResponseScopedPDU -- specified by application 

IN stateReference -- specified by application 

IN statusInformation -- specified by application 

OUT destTransportDomain -- destination transport domain 
OUT destTransportAddress -- destination transport address 
OUT outgoingMessage -- the message to send 

OUT outgoingMessageLength -- the message length 


) 


If the result is an errorIndication, the errorIndication is 
returned to the calling application. No further processing is 
performed. 


If the result is success, the outgoingMessage is sent over the 
transport specified by the transportDomain to the address 
specified by the transportAddress. 


Message Processing is complete. 


A2 


Receiving an SNMP Message from the Network 


This section describes the procedure followed by an SNMP engine 
whenever it receives an SNMP message. 


Please note, that for the sake of clarity and to prevent the text 
from being even longer and more complicated, some details were 
omitted from the steps below. In particular, The elements of 
procedure do not always explicitly indicate when state information 
needs to be released. The general rule is that if state information 
is available when a message is to be "discarded without further 
processing", then the state information must also be released at that 
same time. 


Aza 


1) 


2) 


Case, 


Message Dispatching of received SNMP Messages 
The snmpInPkts counter [RFC1907] is incremented. 


The version of the SNMP message is determined in an 
implementation-dependent manner. If the packet cannot be 
sufficiently parsed to determine the version of the SNMP message, 
then the snmpInASNParseErrs [RFC1907] counter is incremented, and 
the message is discarded without further processing. If the 
version is not supported, then the snmpInBadVersions [RFC1907] 
counter is incremented, and the message is discarded without 
further processing. 
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3) 


5) 


6) 


4.2.2. 
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The origin transportDomain and origin transportAddress are 


determined. 


The message is passed to the version-specific Message Processing 
Model which returns the abstract data elements required by the 


Dispatcher. 
primitive: 


result = 
prepareDataElements ( 
IN transportDomain 
IN transportAddress 
IN wholeMsg 
IN wholeMsgLength 
OUT messageProcessingModel 
OUT securityModel 
OUT securityName 
OUT securityLevel 
OUT contextEngineID 
OUT contextName 
OUT pduVersion 
OUT PDU 
OUT pduType 
OUT sendPduHandle 


OUT maxSizeResponseScopedPDU -- 


OUT statusInformation 


OUT stateReference 


) 


This is performed using the abstract service 


SUCCESS or errorIndication 


origin as determined in step 3. 
origin as determined in step 3. 
as received from the network 
as received from the network 
typically, SNMP version 
Security Model to use 

on behalf of this principal 
Level of Security requested 
data from/at this entity 

data from/in this context 

the version of the PDU 

SNMP Protocol Data Unit 

SNMP PDU type 

handle for a matched request 
maximum size of Response PDU 
success or errorIndication 
(error counter OID and value 
when errorIndication) 
reference to state information 
to be used for a possible 
Response 


If the result is a FAILURE errorIndication, the message is 
discarded without further processing. 


At this point, the abstract data elements have been prepared and 
processing continues as described in Section 4.2.2, PDU 


Dispatching for Incoming Messages. 


PDU Dispatching for Incoming Messages 


The elements of procedure for the dispatching of PDUs depends on the 


value of sendPduHandle. 


If the value of sendPduHandle is <none>, 


then this is a request or notification and the procedures specified 


in Section 4.2.2.1 apply. 
<none>, 


Section 4.2.2.2 apply. 


Case, 


et. al. 


Standards Track 


If the value of snmpPduHandle is not 
then this is a response and the procedures specified in 
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4.2.2.1. Incoming Requests and Notifications 

The following procedures are followed for the dispatching of PDUs 

when the value of sendPduHandle is <none>, indicating this is a 

request or notification. 

1) The combination of contextEngineID and pduType is used to 
determine which application has registered for this request or 
notification. 

2) If no application has registered for the combination, then 


a) The snmpUnknownPDUHandlers counter is incremented. 


b) A Response message is generated using the abstract service 


primitive: 

result = -- SUCCESS or FAILURE 

prepareResponseMessage ( 

IN messageProcessingModel -- as provided by MP module 

IN securityModel -- as provided by MP module 

IN securityName -- as provided by MP module 

IN securityLevel -—- as provided by MP module 

IN contextEnginelD -- as provided by MP module 

IN contextName -- as provided by MP module 

IN pduVersion -- as provided by MP module 

IN PDU -- as provided by MP module 

IN maxSizeResponseScopedPDU -- as provided by MP module 

IN stateReference -- as provided by MP module 

IN statusInformation -- errorIndication plus 
-- snmpUnknownPDUHandlers OID 
—- value pair. 

OUT transportDomain -- destination transportDomain 

OUT transportAddress -- destination transportAddress 

OUT outgoingMessage -- the message to send 

OUT outgoingMessageLength -—- its length 


c) If the result is SUCCESS, then the prepared message is sent to 
the originator of the request as identified by the 
transportDomain and transportAddress. 


d) The incoming message is discarded without further processing. 
Message Processing for this message is complete. 


3) The PDU is dispatched to the application, using the abstract 
service primitive: 
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processPdu ( -- process Request/Notification 
IN messageProcessingModel -- as provided by MP module 
IN securityModel -- as provided by MP module 
IN securityName -- as provided by MP module 
IN securityLevel —- as provided by MP module 
IN contextEnginelD -- as provided by MP module 
IN contextName -- as provided by MP module 
IN pduVersion -- as provided by MP module 
IN PDU -- as provided by MP module 
IN maxSizeResponseScopedPDU -- as provided by MP module 
IN stateReference -- as provided by MP module 


-- needed when sending response 


) 
Message processing for this message is complete. 
4.2.2.2. Incoming Responses 


The following procedures are followed for the dispatching of PDUs 
when the value of sendPduHandle is not <none>, indicating this is a 
response. 


1) The value of sendPduHandle is used to determine, in an 
implementation-defined manner, which application is waiting for 
a response PDU associated with this sendPduHandle. 


2) If no waiting application is found, the message is discarded 
without further processing, and the stateReference is released. 
The snmpUnknownPDUHandlers counter is incremented. Message 
Processing is complete for this message. 


3) Any cached information, including stateReference, about the 
message is discarded. 


4) The response is dispatched to the application using the 
abstract service primitive: 


processResponsePdu ( -- process Response PDU 
IN messageProcessingModel -=- provided by the MP module 
IN securityModel -—- provided by the MP module 
IN securityName —- provided by the MP module 
IN securityLevel —- provided by the MP module 
IN contextEnginelD -- provided by the MP module 
IN contextName -- provided by the MP module 
IN pduVersion -- provided by the MP module 
IN PDU -- provided by the MP module 
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IN statusInformation —- provided by the MP module 
IN sendPduHandle -—- provided by the MP module 
) 


Message Processing is complete for this message. 
4.3. Application Registration for Handling PDU types 
Applications that want to process certain PDUs must register with the 
PDU Dispatcher. Applications specify the combination of 
contextEngineID and pduType(s) for which they want to take 


responsibility 


1) An application registers according to the abstract interface 


primitive: 

statusInformation = —- success or errorIndication 
registerContextEnginelD ( 
IN contextEnginelD -- take responsibility for this one 
IN pduType -- the pduType(s) to be registered 


) 


Note: implementations may provide a means of requesting 
registration for simultaneous multiple contextEngineID values, 
e.g., all contextEngineID values, and may also provide means for 
requesting simultaneous registration for multiple values of 
pduType. 


2) The parameters may be checked for validity; if they are not, then 
an errorIndication (invalidParameter) is returned to the 
application. 

3) Each combination of contextEngineID and pduType can be registered 
only once. If another application has already registered for the 
specified combination, then an errorIndication (alreadyRegistered) 
is returned to the application. 


4) Otherwise, the registration is saved so that SNMP PDUs can be 
dispatched to this application. 


4.4. Application Unregistration for Handling PDU Types 


Applications that no longer want to process certain PDUs must 
unregister with the PDU Dispatcher. 


1) An application unregisters using the abstract service primitive: 
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unregisterContextEnginelD ( 


IN contextEngineID 
IN pduType 
) 
Note: 
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-- give up responsibility for this 
-- the pduType(s) to be unregistered 


implementations may provide means for requesting 


unregistration for simultaneous multiple contextEngineID values, 


e.g., all contextEngineID values, and may also provide means for 
requesting simultaneous unregistration for multiple values of 
pduType. 
2) If the contextEngineID and pduType combination has been 
registered, then the registration is deleted. 
If no such registration exists, then the request is ignored. 
5. Definitions 
5.1. Definitions for SNMP Message Processing and Dispatching 
SNMP-MPD-MIB DEFINITIONS = BEGIN 
IMPORTS 
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 
MODULE-IDENTITY, OBJECT-TYPE, 
snmpModules, Counter32 FROM SNMPv2-SMI; 
snmpMPDMIB MODULE-IDENTITY 
LAST-UPDATED "97112000002" -- 20 November 1997 
ORGANIZATION "SNMPv3 Working Group" 
CONTACT-INFO "WG-email: snmpv3@tis.com 
Subscribe: majordomo@tis.com 
In message body: subscribe snmpv3 
Chair: Russ Mundy 
Trusted Information Systems 
postal: 3060 Washington Road 
Glenwood, MD 21738 
USA 
email: mundy@tis.com 
phone: +1 301-854-6889 
Co-editor: Jeffrey Case 
SNMP Research, Inc. 
postal: 3001 Kimberlin Heights Road 
Knoxville, TN 37920-9716 
USA 
email: case@snmp.com 
phone: +1 423-573-1434 
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Message Processing and Dispatching" 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpMPDAdmin OBJECT IDENTIFIER { snmpMPDMIB 1 } 
snmpMPDMIBObjects OBJECT IDENTIFIER = { snmpMPDMIB 2 } 
snmpMPDMIBConformance OBJECT IDENTIFIER = { snmpMPDMIB 3 } 


== Statistics for SNMP Messages KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpMPDStats OBJECT 


IDENTIFIER ::= 


snmpUnknownSecurityModels OBJECT-TYPE 


SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 


{ snmpMPDMIBObjects 1 } 


DESCRIPTION "The total number of packets received by the SNMP 
engine which were dropped because they referenced a 
securityModel that was not known to or supported by 
the SNMP engine. 
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::= { snmpMPDStats 1 } 


snmpInvalidMsgs OBJECT-TYPE 


SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "The total number of packets received by the SNMP 
engine which were dropped because there were invalid 
or inconsistent components in the SNMP message. 


::= { snmpMPDStats 2 } 


snmpUnknownPDUHandlers OBJECT-TYPE 


SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "The total number of packets received by the SNMP 
engine which were dropped because the PDU contained 
in the packet could not be passed to an application 
responsible for handling the pduType, e.g. no SNMP 
application had registered for the proper 
combination of the contextEngineID and the pduType. 


::= { snmpMPDStats 3 } 


a Conformance information KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1} 
snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2} 


-- Compliance statements 
snmpMPDCompliance MODULE-COMPLIANCE 
STATUS current 


DESCRIPTION "The compliance statement for SNMP entities which 
implement the SNMP-MPD-MIB. 


MODULE -- this module 
MANDATORY-GROUPS { snmpMPDGroup ) 
:= { snmpMPDMIBCompliances 1 } 


snmpMPDGroup OBJECT-GROUP 
OBJECTS { 


snmpUnknownSecurityModels, 
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snmpInvalidMsgs, 
snmpUnknownPDUHandlers 


} 
STATUS 


current 


DESCRIPTION "A collection of objects providing for remote 


monitoring of the SNMP Message Processing and 
Dispatching process. 


{ snmpMPDMIBGroups 1 } 


The SNMPv3 Message Format 


This section defines the SNMPv3 message format and the corresponding 


SNMP version 3 Message Processing Model 


SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS 


SNMPv3Message 


(v3MP) . 


BEGIN 


SEQUENCE { 


-=- identify the layout of the SNMPv3Message 
-- this element is in same position as in SNMPv1 


-=- and SNMPv2c, 
msgVersion INTEGER { snmpv3 


allowing recognition 


(3) 3, 


-- administrative parameters 
msgGlobalData HeaderData, 

-=- security model-specific parameters 
-- format defined by Security Model 
msgSecurityParameters OCTET STRING, 


msgData ScopedPduData 
} 
HeaderData = SEQUENCE { 
msgID INTEGER (0..2147483647), 
msgMaxSize INTEGER (484..2147483647), 
msgFlags OCTET STRING (SIZE(1)), 
SS Re a eed: authFlag 
A E E privFlag 
SS. a li reportablerF lag 
=- Please observe: 
=z .. 00 is OK, means noAuthNoPriv 
== ¿0.1 is OK, means authNoPriv 
a E O) reserved, must NOT be used. 
a pare bal is OK, means authPriv 


msgSecurityModel INTEGER 


(0. .2147483647) 
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ScopedPduData ::= CHOICE { 

plaintext ScopedPDU, 

encryptedPDU OCTET STRING -- encrypted scopedPDU value 
} 
ScopedPDU ::= SEQUENCE { 

contextEngineID OCTET STRING, 

contextName OCTET STRING, 

data ANY -- e.g., PDUs as defined in RFC1905 


END 
6.1. msgVersion 


The msgVersion field is set to snmpv3(3) and identifies the message 
as an SNMP version 3 Message. 


6.2. msgID 


The msgID is used between two SNMP entities to coordinate request 
messages and responses, and by the v3MP to coordinate the processing 
of the message by different subsystem models within the architecture. 


Values for msgID should be generated in a manner that avoids re-use 
of any outstanding values. Doing so provides protection against some 
replay attacks. One possible implementation strategy would be to use 
the low-order bits of snmpEngineBoots [RFC2271] as the high-order 
portion of the msgID value and a monotonically increasing integer for 
the low-order portion of msgID. 


Note that the request-id in a PDU is used by SNMP applications to 
identify the PDU; the msgID is used by the engine to identify the 
message which carries a PDU. The engine may need to identify the 
message even if decrypting of the PDU (and request-id) fails. No 
assumption should be made that the value of the msgID and the value 
of the request-id are equivalent. 


6.3. msgMaxSize 


The msgMaxSize field of the message conveys the maximum message size 
supported by the sender of the message, i.e., the maximum message 
size that the sender can accept when another SNMP engine sends an 
SNMP message (be it a response or any other message) to the sender of 
this message. 
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When an SNMP message is being generated, the msgMaxSize is provided 
by the SNMP engine which generates the message. At the receiving 
SNMP engine, the msgMaxSize is used to determine how big the Response 
to a Request message can be. 


6.4. msgFlags 


The msgFlags field of the message contains several bit fields which 
control processing of the message. 


When the reportableFlag is one, a Report PDU must be returned to the 
sender under those conditions which can cause the generation of 
Report PDUs. When the reportableFlag is zero, then a Report PDU must 
not be sent. The reportableFlag must always be zero when the message 
contains a Report PDU, a response-type PDU (such as a Response PDU), 
or an unacknowledged notification-type PDU (such as an SNMPv2-trap 
PDU). The reportableFlag must always be one for a request-type PDU 
(such as a Get PDU) and an acknowledged notification-type PDU (such 
as an Inform PDU). 


If the reportableFlag is set to one for a message containing a Report 
PDU, a response-type PDU (such as a Response PDU), or an 
unacknowledged notification-type PDU (such as an SNMPv2-trap PDU), 
then the receiver of that message must process it as though the 
reportableFlag had been set to zero. 


If the reportableFlag is set to zero for a message containing a 
request-type PDU (such as a Get PDU) or an acknowledged notification- 
type PDU (such as an Inform PDU), then the receiver of that message 
must process it as though the reportableFlag had been set to one. 


Report PDUs are engine-to-engine communications and are processed 
directly by the SNMPv3 Message Processing Model, and are generally 
not passed to applications for processing, unlike all other PDU 
types. 


Note that the reportableFlag is a secondary aid in determining 
whether a Report PDU must be sent. It is only used in cases where 
the PDU portion of a message cannot be decoded, due to, for example, 
an incorrect ecryption key. If the PDU can be decoded, the PDU type 
forms the basis for decisions on sending Report PDUs. 


The authFlag and privFlag portions of the msgFlags field are set by 
the sender to indicate the securityLevel that was applied to the 
message before it was sent on the wire. The receiver of the message 
must apply the same securityLevel when the message is received and 
the contents are being processed. 
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There are three securityLevels, namely noAuthNoPriv, which is less 
than authNoPriv, which is in turn less than authPriv. See the SNMP 
architecture document [RFC2271] for details about the securitylLevel. 


a) 


Case, 


authFlag 


If the authFlag is set to one, then the securityModel used by the 
SNMP engine which sent the message must identify the securityName 
on whose behalf the SNMP message was generated and must provide, 
in a securityModel-specific manner, sufficient data for the 
receiver of the message to be able to authenticate that 
identification. In general, this authentication will allow the 
receiver to determine with reasonable certainty that the message 
was: 


- sent on behalf of the principal associated with the 
securityName, 


- was not redirected, 
- was not modified in transit, and 
- was not replayed. 


If the authFlag is zero, then the securityModel used by the SNMP 
engine which sent the message must identify the securityName on 
whose behalf the SNMP message was generated but it does not need 
to provide sufficient data for the receiver of the message to 
authenticate the identification, as there is no need to 
authenticate the message in this case. 


privFlag 


If the privFlag is set, then the securityModel used by the SNMP 
engine which sent the message must also protect the scopedPDU in 
an SNMP message from disclosure, i.e., must encrypt/decrypt the 
scopedPDU. If the privFlag is zero, then the securityModel in use 
does not need to protect the data from disclosure. 


It is an explicit requirement of the SNMP architecture that if 
privacy is selected, then authentication is also required. That 
means that if the privFlag is set, then the authFlag must also be 
set to one. 


The combination of the authFlag and the privFlag comprises a Level 
of Security as follows: 


authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv 
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authFlag zero, privFlag one -> invalid combination 
authFlag one, privFlag zero -> securitylevel is authNoPriv 
authFlag one, privFlag one -> securitylevel is authPriv 


6.5. msgSecurityModel 


The v3MP supports the concurrent existence of multiple Security 
Models to provide security services for SNMPv3 messages. The 
msgSecurityModel field in an SNMPv3 Message identifies which Security 
Model was used by the sender to generate the message and therefore 
which securityModel must be used by the receiver to perform security 
processing for the message. The mapping to the appropriate 
securityModel implementation within an SNMP engine is accomplished in 
an implementation-dependent manner. 


6.6. msgSecurityParameters 


The msgSecurityParameters field of the SNMPv3 Message is used for 
communication between the Security Model modules in the sending and 
receiving SNMP engines. The data in the msgSecurityParameters field 
is used exclusively by the Security Model, and the contents and 
format of the data is defined by the Security Model. This OCTET 
STRING is not interpreted by the v3MP, but is passed to the local 
implementation of the Security Model indicated by the 
msgSecurityModel field in the message. 


6.7. scopedPduData 


The scopedPduData field represents either the plain text scopedPDU if 
the privFlag in the msgFlags is zero, or it represents an 
encryptedPDU (encoded as an OCTET STRING) which must be decrypted by 
the securityModel in use to produce a plaintext scopedPDU. 


6.8. scopedPDU 


The scopedPDU contains information to identify an administratively 
unique context and a PDU. The object identifiers in the PDU refer to 
managed objects which are (expected to be) accessible within the 
specified context. 


6.8.1. contextEngineID 
The contextEngineID in the SNMPv3 message, uniquely identifies, 


within an administrative domain, an SNMP entity that may realize an 
instance of a context with a particular contextName. 
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For incoming messages, the contextEngineID is used to determine to 
which application the scopedPDU will be sent for processing. 


For outgoing messages, the v3MP sets the contextEngineID to the value 
provided by the application in the request for a message to be sent. 


6.8.2. contextName 


The contextName field in an SNMPv3 message, in conjunction with the 
contextEngineID field, identifies the particular context associated 
with the management information contained in the PDU portion of the 
message. The contextName is unique within the SNMP entity specified 
by the contextEngineID, which may realize the managed objects 
referenced within the PDU. An application which originates a message 
provides the value for the contextName field and this value may be 
used during processing by an application at the receiving SNMP 
Engine. 


6.8.3. data 


The data field of the SNMPv3 Message contains the PDU. Among other 
things, the PDU contains the PDU type that is used by the v3MP to 
determine the type of the incoming SNMP message. The v3MP specifies 
that the PDU must be one of those specified in [RFC1905]. 


7. Elements of Procedure for v3MP 


This section describes the procedures followed by an SNMP engine when 
generating and processing SNMP messages according to the SNMPv3 
Message Processing Model. 


Please note, that for the sake of clarity and to prevent the text 
from being even longer and more complicated, some details were 
omitted from the steps below. 


a) Some steps specify that when some error conditions are 
encountered when processing a received message, a message 
containing a Report PDU is generated and the received message 
is discarded without further processing. However, a Report-PDU 
must not be generated unless the reportableFlag is set in the 
received message. 


b) The elements of procedure do not always explicitly indicate 
when state information needs to be released. The general rule 
is that if state information is available when a message is to 
be "discarded without further processing", then the state 
information must also be released at that same time. 
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Polo 


Prepare an Outgoing SNMP Message 


This section describes the procedure followed to prepare an SNMPv3 
message from the data elements passed by the Message Dispatcher. 


1) 


Case, 


The Message Dispatcher may request that an SNMPv3 message 
containing a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest- 
PDU, SetRequest-PDU, InformRequest-PDU, or SNMPv2-Trap-PDU be 
prepared for sending. 


a) It makes such a request according to the abstract service 


primitive: 
statusInformation = -=- success or errorIndication 
prepareOutgoingMessage ( 
IN transportDomain —- requested transport domain 
IN transportAddress -- requested destination address 
IN messageProcessingModel -- typically, SNMP version 
IN securityModel -- Security Model to use 
IN securityName -- on behalf of this principal 
IN securityLevel -- Level of Security requested 
IN contextEnginelD -- data from/at this entity 
IN contextName -- data from/in this context 
IN pduVersion -- version of the PDU 
IN PDU -- SNMP Protocol Data Unit 
IN expectResponse -- TRUE or FALSE 
IN sendPduHandle -- the handle for matching 
-- incoming responses 
OUT destTransportDomain -- destination transport domain 
OUT destTransportAddress -- destination transport address 
OUT outgoingMessage -- the message to send 
OUT outgoingMessageLength -- the length of the message 


b) A unique msgID is generated. The number used for msgID should 
not have been used recently, and must not be the same as was 
used for any outstanding request. 


* SNMPv3 does not use the values of expectResponse or 
pduVersion. 


The Message Dispatcher may request that an SNMPv3 message 
containing a Response-PDU or Report-PDU be prepared for sending. 


a) It makes such a request according to the abstract service 
primitive: 
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Case, 


result = -- SUCCESS or FAILURE 
prepareResponseMessage ( 
IN messageProcessingModel -—- typically, SNMP version 
IN securityModel -- same as on incoming request 
IN securityName -- same as on incoming request 
IN securityLevel -- same as on incoming request 
IN contextEnginelD -- data from/at this SNMP entity 
IN contextName -- data from/in this context 
IN pduVersion -- version of the PDU 
IN PDU —- SNMP Protocol Data Unit 
IN maxSizeResponseScopedPDU -- maximum size of Response PDU 
IN stateReference -- reference to state 
-=- information presented with 
-- the request 
IN statusInformation -=- success or errorIndication 


-- error counter OID and value 
-- when errorIndication 


OUT transportDomain -- destination transport domain 
OUT transportAddress -- destination transport address 
OUT outgoingMessage -- the message to send 

OUT outgoingMessageLength -- the length of the message 


b) The cached information for the original request is retrieved 
via the stateReference, including 


- msglD, 

- contextEnginelD, 

- contextName, 

- securityModel, 

- securityName, 

- securityLevel, 

- securityStateReference, 
- reportableFlag, 

- transportDomain, and 

- transportAddress. 


The SNMPv3 Message Processing Model does not allow cached data 
to be overridden, except by error indications as detailed in 
(3) below. 


If statusInformation contains values for an OID/value combination 
(potentially also containing a securityLevel value, 
contextEnginelD value, or contextName value), then 


a) If reportableFlag is zero, then the original message is 


discarded, and no further processing is done. A result of 
FAILURE is returned. SNMPv3 Message Processing is complete. 
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b) If a PDU is provided, it is the PDU from the original request. 
If possible, extract the request-id. 
c) A Report PDU is prepared: 


1) the varBindList is set to contain the OID and value from the 
statusInformation 


2) error-status is set to 0 
3) error-index is set to 0. 


4) request-id is set to the value extracted in step b) 
Otherwise, request-id is set to 0 


d) The errorIndication in statusInformation may be accompanied by 
a securityLevel value, a contextEngineID value, or a 
contextName value. 


1) If statusInformation contains a value for securitylevel, 
then securityLevel is set to that value, otherwise it is set 
to noAuthNoPriv. 


2) If statusInformation contains a value for contextEnginelD, 
then contextEnginelD is set to that value, otherwise it is 
set to the value of this entity's snmpEnginelD. 


3) If statusInformation contains a value for contextName, then 
contextName is set to that value, otherwise it is set to the 
default context of "" (zero-length string). 


e) PDU is set to refer to the new Report-PDU. The old PDU is 
discarded. 


f) Processing continues with step 6) below. 


4) If contextEnginelD is not yet determined, then the contextEnginelD 
is determined, in an implementation-dependent manner, possibly 
using the transportDomain and transportAddress. 


5) If the contextName is not yet determined, the contextName is set 
to the default context. 


6) A scopedPDU is prepared from the contextEngineID, contextName, and 
PDU. 
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msgGlobalData is constructed as follows 


a) 


et. 


The msgVersion field is set to snmpv3(3). 


msgID is set as determined in step 1 or 2 above. 


msgMaxSize is set to an implementation-dependent value. 


msgFlags are set as follows: 


If securityLevel specifies noAuthNoPriv, 


privFlag are both set to zero. 


aut 
to 


If securityLevel specifies 
to one and privFlag is set 


If securityLevel specifies aut 


one and privFlag is set to 


If the PDU is a Response-PDU, 
then the reportableFlag is set 


then authFlag and 


hNoPriv, then authFlag is set 
zero. 
hPriv, then authFlag is set to 


one. 


Report-PDU or SNMPv2-Trap-PDU, 
to zero. 


If the PDU is a GetRequest-PDU, GetNextRequest-PDU, 


GetBulkRequest-PDU, SetRequest 
then the reportableFlag is set 


All other msgFlags bits are se 


-PDU, or InformRequest-PDU 
to one. 


t to zero. 


msgSecurityModel is set to the value of securityModel 


the PDU is a Response-PDU or Report-PDU, then 


The specified Security Model is called to generate the message 
according to the primitive: 


statusInformation 


generateResponseMsg ( 


I 


al. 


OHHHHHHHH 


N messageProcessingModel -- 
globalData 
maxMessageSize 
securityModel 
securityEnginelD 
securityName 
securityLevel 
scopedPDU 
securityStateReference -- 
securityParameters 


2222222424 


H 


C 


Standards Trac 


SNMPv3 Message Processing 
Model 

msgGlobalData from step 7 
from msgMaxSize (step 7c) 
as determined in step 7e 
the value of snmpEngineID 
on behalf of this principal 
for the outgoing message 

as prepared in step 6) 

as determined in step 2 
filled in by Security Module 


k [Page 27] 


RFC 2272 


Case, 


b) 
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OUT wholeMsg -- complete generated message 
OUT wholeMsgLength -- length of generated message 
) 


If, upon return from the Security Model, the statusInformation 
includes an errorIndication, then any cached information about 
the outstanding request message is discarded, and an 
errorIndication is returned, so it can be returned to the 
calling application. SNMPv3 Message Processing is complete. 


A SUCCESS result is returned. SNMPv3 Message Processing is 
complete. 


the PDU is a GetRequest-PDU, GetNextRequest-PDU, 
BulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, or or 


SNMPv2-Trap-PDU, then 


a) 


et. 


If the PDU is an SNMPv2-Trap-PDU, then securityEnginelD is set 
to the value of this entity's snmpEnginelD. 


Otherwise, the snmpEngineID of the target entity is determined, 
in an implementation-dependent manner, possibly using 
transportDomain and transportAddress. The value of 
securityEngineID is set to the value of the target entity’s 
snmpEnginelD. 


The specified Security Model is called to generate the message 
according to the primitive: 


statusInformation = 
generateRequestMsg ( 


IN messageProcessingModel -- SNMPv3 Message Processing Model 
IN globalData -- msgGlobalData, from step 7 

IN maxMessageSize -- from msgMaxSize in step 7 c) 

IN securityModel -- as provided by caller 

IN securityEngineID -- authoritative SNMP entity 

IN securityName -- as provided by caller 

IN securityLevel -- as provided by caller 

IN snmpEngineID -- as determined in step 9 a) 

IN scopedPDU -- as prepared in step 6 

OUT securityParameters -- filled in by Security Module 
OUT wholeMsg -- complete generated message 

OUT wholeMsgLength -- length of the generated message 
) 
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d) 


SNMPv3 Management 


TÉ, 
includes an errorIndication, 


calling application, 


upon return from the Security Model, 
then the message is discarded, 
the errorIndication is returned, 
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the statusInformation 
and 
so it can be returned to the 


and no further processing is done. 


SNMPv3 Message Processing is complete. 


Information about the outgoing message is cached, 
(implementation-specific). 
be cached includes the values of: 


stateReference is created 


Information to 


sendPduHandle 
msgID 
snmpEngineID 
securityModel 
securityName 
securityLevel 
contextEngineID 
contextName 


A SUCCESS result is returned. 
complete. 


anda 


SNMPv3 Message Processing is 


Prepare Data Elements from an Incoming SNMP Message 


This section describes the procedure followed to extract data from an 


SNMPv3 message, 


and to prepare the data elements required for further 


processing of the message by the Message Dispatcher. 


1) 


Case, 


The message is passed in from the Message Dispatcher according to 
the abstract service primitive: 


result 


et. 


prepareDataElements ( 


SUCCESS or errorIndication 


IN transportDomain -=- origin transport domain 

IN transportAddress —- origin transport address 

IN wholeMsg -- as received from the network 
IN wholeMsgLength -- as received from the network 
OUT messageProcessingModel -- typically, SNMP version 

OUT securityModel -- Security Model to use 

OUT securityName -- on behalf of this principal 
OUT securityLevel -- Level of Security requested 
OUT contextEnginelD -- data from/at this entity 

OUT contextName -- data from/in this context 

OUT pduVersion -- version of the PDU 

OUT PDU -- SNMP Protocol Data Unit 

OUT pduType -- SNMP PDU type 

OUT sendPduHandle -- handle for matched request 

OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 
al. Standards Track [Page 29] 
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Case, 


OUT statusInformation -- success or errorIndication 
-- error counter OID and value 
-- when errorIndication 


OUT stateReference -- reference to state information 
-- to be used for a possible 
) -- Response 


If the received message is not the serialization (according to 
the conventions of [RFC1906]) of an SNMPv3Message value, then the 
snmpInASNParseErrs counter [RFC1907] is incremented, the message 
is discarded without further processing, and a FAILURE result is 
returned. SNMPv3 Message Processing is complete. 


The values for msgVersion, msgID, msgMaxSize, msgFlags, 
msgSecurityModel, msgSecurityParameters, and msgData are extracted 
from the message. 


If the value of the msgSecurityModel component does not match a 
supported securityModel, then the snmpUnknownSecurityModels 
counter is incremented, a Report PDU is generated, the message is 
discarded without further processing, and a FAILURE result is 
returned. SNMPv3 Message Processing is complete. 


The securityLevel is determined from the authFlag and the 
privFlag bits of the msgFlags component as follows: 


a) If the authFlag is not set and the privFlag is not set, then 
securitylevel is set to noAuthNoPriv. 


b) If the authFlag is set and the privFlag is not set, then 
securitylevel is set to authNoPriv. 


c) If the authFlag is set and the privFlag is set, then 
securitylevel is set to authPriv. 


d) If the authFlag is not set and privFlag is set, then the 
snmpInvalidMsgs counter is incremented, a Report PDU is 
generated, the message is discarded without further processing, 
and a FAILURE result is returned. SNMPv3 Message Processing is 
complete. 


The security module implementing the Security Model as specified 
by the securityModel component is called for authentication and 


privacy services. This is done according to the abstract service 
primitive: 
statusInformation = -- errorIndication or success 


-- error counter OID and 
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—- value if error 
processIncomingMsg ( 


IN messageProcessingModel -- SNMPv3 Message Processing Model 
IN expectResponse -- TRUE or FALSE 
IN maxMessageSize -—- of the sending SNMP entity 
IN securityParameters -- for the received message 
IN securityModel -- for the received message 
IN securityLevel -- Level of Security 
IN wholeMsg -- as received on the wire 
IN wholeMsgLength -- length as received on the wire 
OUT securityEngineID -- authoritative SNMP entity 
OUT securityName -- identification of the principal 
OUT scopedPDU, -- message (plaintext) payload 
OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 
OUT securityStateReference -- reference to security state 
) =- information, needed for 
-- response 


an errorIndication is returned by the security module, then 


If statusInformation contains values for an OID/value pair, 
then a Report PDU is generated. 


1) If the scopedPDU has been returned from ProcessIncomingMsg 
then determine contextEngineID, contextName, and PDU. 


2) Information about the message is cached and a 
stateReference is created (implementation-specific). 
Information to be cached includes the values of: 


msgVersion, 

msgID, 

securityLevel, 

msgFlags, 

msgMaxSize, 
securityModel, 
maxSizeResponseScopedPDU, 
securityStateReference 


3) Request that a Report-PDU be prepared and sent, according 
to the abstract service primitive: 


result = -- SUCCESS or FAILURE 
returnResponsePDU ( 

IN messageProcessingModel —- SNMPv3 (3) 

IN securityModel -- same as on incoming request 
IN securityName -- from ProcessIncomingMsg 

IN securityLevel -- same as on incoming request 
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10) 


Case, 


IN contextEngineID -- from step 6 a) 1) 

IN contextName -- from step 6 a) 1) 

IN pduVersion -- SNMPv2-PDU 

IN PDU -- from step 6 a) 1) 

IN maxSizeResponseScopedPDU -- from ProcessIncomingMsg 

IN stateReference -- from step 6 a) 2) 

IN statusInformation -- from ProcessIncomingMsg 

OUT transportDomain -- destination's transport 
-- domain 

OUT transportAddress -- destination's transport 
-- address 

OUT outgoingMessage -- the message to send 

OUT outgoingMessageLength -- the length of the message 


<~ 


b) The incoming message is discarded without further processing, 
and a FAILURE result is returned. SNMPv3 Message Processing is 
complete. 


The scopedPDU is parsed to extract the contextEngineID, the 
contextName and the PDU. If any parse error occurs, then the 
snmpInASNParseErrs counter [RFC1907] is incremented, the security 
state information is discarded, the message is discarded without 
further processing, and a FAILURE result is returned. SNMPv3 
Message Processing is complete. 


The pduVersion is set to an SNMPv2-PDU. 


The pduType is determined, in an implementation-dependent manner, 
to be: 


GetRequest-PDU, 
GetNextRequest-PDU, 
GetBulkRequest-PDU, 
SetRequest-PDU, 

- an InformRequest-PDU, 
- an SNMPv2-Trap-PDU, 

- a Response-PDU, or 

- a Report-PDU. 


Mopo 


If the pduType is a Response-PDU or Report-PDU, then 


a) The value of the msgID component is used to find the cached 
information for a corresponding outstanding Request message. 
If no such outstanding Request message is found, then the 
security state information is discarded, the message is 
discarded without further processing, and a FAILURE result is 
returned. SNMPv3 Message Processing is complete. 
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sendPduHandle is retrieved from the cached information. 


Otherwise, sendPduHandle is set to <none>, an implementation 
defined value. 


If 


a) 


et. 


the pduType is a Report-PDU, then 


statusInformation is created using the contents of the 
Report-PDU, in an implementation-dependent manner. This 
statusInformation will be forwarded to the application 
associated with the sendPduHandle. 


Any cached information about the outstanding Request message 
message is discarded. 


The security state information for this incoming message is 
discarded. 


stateReference is set to <none> 


A SUCCESS result is returned. SNMPv3 Message Processing is 
complete. 


the pduType is a Response-PDU, then 


The cached data for the outstanding request, referred to by 
stateReference, is retrieved, including 


- snmpEnginelD 

- securityModel 

- securityName 

- securityLevel 

- contextEnginelD 
- contextName 


If the values extracted from the incoming message differ from 
the cached data, then the security state information is 
discarded, any cached information about the outstanding 
Request message is discarded, the incoming message is 
discarded without further processing, and a FAILURE result is 
returned. SNMPv3 Message Processing is complete. 


Otherwise, any cached information about the outstanding 
Request message is discarded, and stateReference is set to 
<none>. 


A SUCCESS result is returned. SNMPv3 Message Processing is 
complete. 
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13) If the pduType is a GetRequest-PDU, GetNextRequest-PDU, 
GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, then 


a) If the value of securityEngineID is not equal to the value of 
snmpEngineID, then the security state information is 
discarded, any cached information about the outstanding 
Request message is discarded, the incoming message is 
discarded without further processing, and a FAILURE result is 
returned. SNMPv3 Message Processing is complete. 


b) Information about the message is cached and a stateReference 
is created (implementation-specific). Information to be 
cached includes the values of: 


msgVersion, 

msgID, 

securityLevel, 

msgFlags, 

msgMaxSize, 
securityModel, 
maxSizeResponseScopedPDU, 
securityStateReference 


c) A SUCCESS result is returned. SNMPv3 Message Processing is 
complete. 


14) If the pduType is an SNMPv2-Trap-PDU, then A SUCCESS result is 
returned. SNMPv3 Message Processing is complete. 


8. Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 
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The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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10. Security Considerations 


The Dispatcher coordinates the processing of messages to provide a 
level of security for management messages and to direct the SNMP PDUs 
to the proper SNMP application(s). 


A Message Processing Model, and in particular the V3MP defined in 
this document, interacts as part of the Message Processing with 
Security Models in the Security Subsystem via the abstract service 
interface primitives defined in [RFC2271] and elaborated above. 


The level of security actually provided is primarily determined by 
the specific Security Model implementation(s) and the specific SNMP 
application implementation(s) incorporated into this framework. 
Applications have access to data which is not secured. Applications 
should take reasonable steps to protect the data from disclosure, and 
when they send data across the network, they should obey the 
securityLevel and call upon the services of an Access Control Model 
as they apply access control. 


The values for the msgID element used in communication between SNMP 

entities must be chosen to avoid replay attacks. The values do not 

need to be unpredictable; it is sufficient that they not repeat. 
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and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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